UNIVERSIDADE FEDERAL DE SANTA MARIA
CENTRO DE TECNOLOGIA
CURSO DE CIÊNCIA DA COMPUTAÇÃO
AUTOMAÇÃO DE INTERFACES GRÁFICAS
PARA MODELOS DE SIMULAÇÃO DE
CULTURAS AGRÍCOLAS COM BASE EM
LINGUAGEM DE PROGRAMAÇÃO VISUAL
TRABALHO DE GRADUAÇÃO
Romulo Pulcinelli Benedetti
Santa Maria, RS, Brasil
2016
AUTOMAÇÃO DE INTERFACES GRÁFICAS PARA
MODELOS DE SIMULAÇÃO DE CULTURAS AGRÍCOLAS
COM BASE EM LINGUAGEM DE PROGRAMAÇÃO VISUAL
Romulo Pulcinelli Benedetti
Trabalho de Graduação apresentado ao Curso de Ciência da Computação da
Universidade Federal de Santa Maria (UFSM, RS), como requisito parcial para
a obtenção do grau de
Bacharel em Ciência da Computação
Orientadora: Profł. Drł. Andrea Schwertner Charão
Santa Maria, RS, Brasil
2016
Universidade Federal de Santa Maria
Centro de Tecnologia
Curso de Ciência da Computação
A Comissão Examinadora, abaixo assinada,
aprova o Trabalho de Graduação
AUTOMAÇÃO DE INTERFACES GRÁFICAS PARA MODELOS DE
SIMULAÇÃO DE CULTURAS AGRÍCOLAS COM BASE EM
LINGUAGEM DE PROGRAMAÇÃO VISUAL
elaborado por
Romulo Pulcinelli Benedetti
como requisito parcial para obtenção do grau de
Bacharel em Ciência da Computação
COMISSÃO EXAMINADORA:
Andrea Schwertner Charão, Drł.
(Presidente/Orientadora)
Nereu Augusto Streck, Prof. Dr. (UFSM)
João Vicente Ferreira Lima, Prof. Dr. (UFSM)
Santa Maria, 06 de Julho de 2016.
RESUMO
Trabalho de Graduação
Curso de Ciência da Computação
Universidade Federal de Santa Maria
AUTOMAÇÃO DE INTERFACES GRÁFICAS PARA MODELOS DE SIMULAÇÃO
DE CULTURAS AGRÍCOLAS COM BASE EM LINGUAGEM DE PROGRAMAÇÃO
VISUAL
AUTOR: ROMULO PULCINELLI BENEDETTI
ORIENTADORA: ANDREA SCHWERTNER CHARÃO
Local da Defesa e Data: Santa Maria, 06 de Julho de 2016.
A automação de tarefas é uma forma bastante eficiente pela qual podemos reduzir custos
e aumentar a produtividade e qualidade da atividade humana. A computação por si é uma
ferramenta para atingir a automação de tarefas, com vários exemplos de softwares focados em
automatizar tarefas específicas sob comando do usuário, sendo a automatização destes softwares
um campo a parte. Observamos a aproximação destes softwares a abordagens mais naturais ao
raciocínio humano, por meio de interfaces gráficas e contextualização dos elementos com base
no mundo real, tornando estes softwares menos distantes do paradigma de interação do humano
com a realidade. Desta forma este trabalho objetiva abordar a utilização de tecnologias voltadas
a programação visual, em especial a biblioteca para criação de linguagens visuais, Blockly, para
melhorar a abordagem de automação de tarefas, com foco em softwares gráficos de modelagem
matemática agrícola, assim inserindo a atividade de automatizar estes softwares gráficos, dentro
do mesmo domínio de abstração que as atividades destes softwares ocorrem.
Palavras-chave: Automação de Software. Linguagens de Programação Visual. Modelos de
Simulação de Culturas Agrícolas. Automação de Interfaces Gráficas. Blockly.
SUMÁRIO
1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.1 Objetivos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.1.1 Objetivo Geral. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.1.2 Objetivos Específicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.2 Justificativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2 REVISÃO DE LITERATURA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1 Automação e suas abordagens dentro da computação . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2 Programação visual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3 Modelos matemáticos de simulação de culturas agrícolas. . . . . . . . . . . . . . . . . . . . . . . . . 11
3 DESENVOLVIMENTO. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.1 Concepção . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.1.1 Elaboração dos casos de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.1.2 Analise dos casos de uso em outras ferramentas de automação . . . . . . . . . . . . . . . . . . . . . 20
3.1.3 Coleta dos requisitos funcionais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2 Modelagem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2.1 Entradas e saídas do software a ser autoamatizado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2.2 Modelagem do software Automatizador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.3 Desenvolvimento do software. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.3.1 Interação entre automatizador e software a ser automatizado . . . . . . . . . . . . . . . . . . . . . . . 27
3.3.2 Construção de automatizações. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.3.3 Codificação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.3.4 Blockly em uma aplicação Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.3.5 Interação e pesquisa por regiões na tela do sistema operacional . . . . . . . . . . . . . . . . . . . . 29
3.3.6 modelagem das funcionalidades no softwares . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4 RESULTADOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.1 Validando solução com os casos de teste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.1.1 Simanihot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5 CONCLUSÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
REFERÊNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
6
1 INTRODUÇÃO
No desenvolvimento de software, áreas de conhecimento como engenharia de software
e qualidade de software investigam processos e normas, com o objetivo de reduzir a quantia
de recursos necessários e garantir a qualidade de software produzido. Um dos produtos destas
áreas, envolvendo automação, foi o campo de conhecimento de testes de software.
Sendo que o software pode realizar diversas tarefas, e estas podem assumir diversos
estados, qualquer abordagem de teste de software, numa situação ideal deveria avaliar todas
estas tarefas e seus estados para fornecer as melhores informações possíveis sobre a qualidade
do software, o que facilmente pode se tornar uma tarefa repetitiva e de longa duração e na
maioria dos casos nem sempre é possível, segundo (MYERS; SANDLER; BADGETT, 2011,
pag. 10).
Embora nem sempre seja possível testar todos os estados possíveis, é possível realizar
os testes em uma faixa conhecida e finita de estados. Nestes casos, usar ferramentas como
frameworks voltados a automatização destes testes agiliza a tarefa de repetir os testes, como na
abordagem de testes de regressão onde todos os testes devem ser executados novamente a cada
ciclo de desenvolvimento.
Estas ferramentas oferecem também uma série de vantagens tais como precisão ao re-
duzir a necessidade da atenção humana durante o andamento da tarefa, acelerando atividades e
melhorando o aproveitamento do tempo de trabalho humano.
Alguns destes frameworks, embora voltados a realização de testes, poderiam ser usa-
dos para automatizar programas gráficos. Um exemplo disso é o Robot Framework (ROBOT
FRAMEWORK, 2015). Entretanto, são ferramentas que, apesar de cobrirem de forma bastante
detalhada a automação de testes, não são as mais adequadas à modelagem da automatização
de softwares gráficos, dependem de um domínio de assuntos de diversos campos da área de
Ciências da computação e em muitos casos, domínio da especificação e arquitetura do software
a ser automatizado ou ainda alterações a nível de codificação no programa a ser automatizado.
outros casos particulares de automatização focada em tarefas de TI são os próprios
terminais ou ainda utilitários como shell, make e afins. Tratam-se de ferramentas e linguagens
voltadas para automatização do desenvolvimento e de tarefas administrativas, também inade-
quadas à automatização de programas gráficos, seja por serem bastante limitadas a um mundo
formalmente textual, pela complexidade de sua sintaxe ou ainda pela abstração focada em ta-
7
refas comuns apenas para profissionais de TI e para software que oferece interface com estes
utilitários.
Existem também ferramentas destinadas à automação de software gráfico, como a lin-
guagem script de automatização Autoit (AUTOIT, 2015). Ainda assim, é uma ferramenta que
exige o domínio de um nível de abstração elevado, perceptivelmente diferente da abstração em
que a atividade se dá, em um ambiente gráfico, focado em facilidades visuais de interação.
A automatização de tarefas pode ser aproximada do usuário por meio de abordagens
mais visuais e sintaxe mais contextualizada à modelagem de tarefas genéricas em interfaces
gráficas, com o uso de linguagem visual para descrição das automações, onde um exemplo
de ferramenta para construção de linguagens visuais é a biblioteca Blockly (BLOCKLYRE-
SOURCE, 2015) usada neste projeto.
Um tipo de software que se beneficiaria da automatização de tarefas é o de simulação de
culturas agrícolas. Os modelos de simulação vem sendo refinados para prever o comportamento
(por exemplo, taxa de crescimento) de diferentes cultivares sob determinadas condições do am-
biente (por exemplo, volume de chuvas). Alguns exemplos de modelos em uso hoje em dia são
SoySim (SOYSIM, 2015) (soja), Simanihot (SIMANIHOT, 2015) (mandioca) e DSSAT (De-
cision Support System for Agrotechnology Transfer) (DECISION SUPPORT SYSTEM FOR
AGROTECHNOLOGY TRANSFER , DSSAT) (diversos cultivares). Embora estejam se tor-
nando significativamente mais fáceis de interagir por via gráfica, dependendo das atividades
realizadas e da forma como o modelo as realiza, trabalhar com estes programas pode se tornar
uma atividade manual repetitiva e demorada. Tarefas como simulações em climas futuros é um
dos exemplos mais notórios desta situação.
A automatização destes modelos via uma abordagem mais visual permitiria a obtenção
das vantagens aqui discutidas, sem deslocar o utilizador de sua área de domínio, a interface
gráfica.
1.1 Objetivos
1.1.1 Objetivo Geral
O principal objetivo deste trabalho é tornar possível a automação de tarefas em inter-
faces gráficas por meio da simplificação de uma abordagem visual com base na biblioteca de
programação visual Blockly (BLOCKLYRESOURCE, 2015), dentro do contexto de modelos
8
de simulação de culturas agrícolas.
1.1.2 Objetivos Específicos
Fornecer uma solução menos formal e textual, mais visual e contextualizada, de automa-
tização;
Automatizar tarefas computacionais em interfaces gráficas no campo de modelagem ma-
temática agrícola;
Auxiliar o campo de pesquisa e trabalho com modelos matemáticos de culturas agrícolas;
1.2 Justificativa
A automação de tarefas é hoje em dia um processo fundamental para a obtenção de re-
sultados ágeis e de qualidade, tanto na produção de um produto ou no fornecimento de serviços,
assim como na execução de tarefas pessoais. Representa também redução de custos, o que abre
novas possibilidades permitindo trabalhos mais complexos e maiores chances de sucesso. En-
tretanto, ferramentas de automação na computação têm exigido um domínio de abordagens de
abstração que, em geral, vão além da abstração com a qual, usuários finais de outras áreas estão
acostumados. Uma abstração mais próxima ao nível em que estas tarefas ocorrem tornaria a
automação um processo mais intuitivo.
Uma destas áreas de conhecimento é a Fitotecnia, mais especificamente, estudos do de-
senvolvimento da fenologia e produtividade de culturas que hoje utilizam modelos de simulação
de culturas agrícolas. Essa área evoluiu para programas com interfaces gráficas, objetivando al-
cançarem e beneficiarem mais pessoas, leigas em computação porém fluentes na área de conhe-
cimento da ferramenta. Em alguns casos, as tarefas realizadas com estes simuladores envolvem
interações repetitivas para obter uma grande faixa de amostragem de resultados, tarefas estas
que se beneficiariam da automatização e estariam igualmente acessíveis ao domínio de seus
usuários, caso esta automatização pudesse ser realizada dentro deste domínio de entendimento,
um ambiente e uma metodologia visual.
9
2 REVISÃO DE LITERATURA
Na sequência serão apresentados conceitos relativos aos conteúdos abordados nesse tra-
balho, descrevendo a automação, sua utilização dentro computação na área de TI e os resultados
até então obtidos na automatização de tarefas mais genéricas, assim como linguagens de pro-
gramação visual e o Blockly, ferramenta com a qual este aspecto será tratado.
2.1 Automação e suas abordagens dentro da computação
A automação é a execução de tarefas por meio de máquinas e computadores, antes exe-
cutáveis apenas por humanos (PARASURAMAN; SHERIDAN; WICKENS, 2000). Segundo
NOF (NOF, 2009, pág. 124), a automação teve um impacto significativo na economia e de-
senvolvimento tecnológico da sociedade. É um elemento-chave para o alcance de produtos e
serviços de alta qualidade e baixo custo. Uma das áreas impactadas pela automação foi a preci-
são em um ciclo autoalimentado, onde a automação melhora a precisão e por sua vez a precisão
melhora a automação (DONMEZ; SOONS, 2008).
A automação da informação por meio de computadores, segundo NOF (NOF, 2009, pág.
3) é um processo dos dias atuais, onde temos vendas automatizadas de passagens, conexões de
chamadas em nossos telefones, realizadas de forma automática, dentre outras mudanças advin-
das da automatização. Temos também a produção e manufatura por intermédio da robótica. No
final das contas, o impacto da informática promoveu não uma intensa automatização pas-
siva, mas também, segundo VENKATRAMAN(VENKATRAMAN, 1994), tem criado e man-
tido flexíveis redes de negócios, inclusive transformando a forma como realizamos negócios e
atividades.
Dentro da área de computação, observamos a automação agilizar e refinar tarefas como
testes, desenvolvimento e manutenção de projetos, devido ao reconhecimento de que o desen-
volvimento de software muitas vezes consiste na criação sistemática de componentes que devem
aderir a um conjunto bem específico de restrições (BARRY; KEMERER; SLAUGHTER, 2007).
Segundo BARRY; KEMERER; SLAUGHTER(BARRY; KEMERER; SLAUGHTER,
2007), a automação do processo de desenvolvimento tem o potencial de reduzir o erro humano
em código que deve se adequar a sintaxe e restrições precisas, podendo inclusive produzir soft-
ware de melhor qualidade que o produzido manualmente, considerando que o talento em desen-
volvimento de software é escasso, representando também uma redução de custo. Também reduz
10
a necessidade de interação humana com tarefas secundárias ou de pouco interesse, contribuindo
para redução da complexidade da tarefa.
Dentre tarefas comuns na área de TI, temos a automatização de tarefas administrativas
via linguagens e ferramentas tais como um shell e linguagem script específica, ou ainda ferra-
mentas de automatização focadas em tarefas de desenvolvimento, como make, ferramenta de
automação de builds, ou como Robot Framework, ferramenta voltada à automação de testes
(UNIX SHELL, 2015; GNU MAKE, 2015; ROBOT FRAMEWORK, 2015).
Considerando que TI não é a única área onde tarefas repetitivas, bem definidas e res-
tritas ocorrem, o interesse em automatizar estas tarefas resultou em software tal como o Au-
toIt(AUTOIT, 2015), para plataforma Windows, um programa que permite automatizar progra-
mas com interface por meio da descrição da automatização em uma linguagem script, podendo
gerar executáveis independentes que rodam em computadores que não tenham o AutoIt insta-
lado. Essa ferramenta tem à disposição uma grande diversidade de bibliotecas com funções
prontas, tendo inclusive uma IDE voltada para sua linguagem de automação. Outro exemplo
é o Automator, que permite automatizar tarefas repetitivas em plataformas Macintosh, permi-
tindo construir workflows por meio de unidades modulares chamadas ações; apesar de conter
diversas ações pre estabelecidas, é possível inserir novas ações por meio de linguagens como
AppleScript e Objective-C (AUTOMATOR, 2015).
Existem outras ferramentas que se propõem a solucionar estes problemas de automati-
zação em interfaces gráficas, com características diversas, algumas delas proprietárias, outras
com uma linguagem mais visual e informal que linguagens script e código tradicional, tais
como o UiPath, Sekulix e o TestComplete (UIPATH, 2015; TESTCOMPLETE, 2015; SIKULI,
2015), ferramentas que abordam a automação de uma forma mais abstrata, porém com uma
flexibilidade lógica limitada por esta abstração.
2.2 Programação visual
Segundo SHU(SHU, 1988), programação visual é “o uso de representações gráficas sig-
nificativas no processo de programação” realizada em uma linguagem que SHU define como
“uma linguagem que utiliza alguma representação visual para completar o que outrora deve-
ria ser escrito em uma linguagem uni-dimensional tradicional”. Esta definição hoje tem se
mostrado um tanto ampla e tem apresentado diversas contextualizações como podemos ver em
(KOEGEL; HEINES, 1993), que apresenta programação visual no contexto de autoria multimí-
11
dia.
No contexto do presente projeto, programação visual representa a programação de tare-
fas de automatização de programas com interface gráfica, com base em elementos visuais por
meio do Blockly (BLOCKLYRESOURCE, 2015). Esta é uma biblioteca de código aberto des-
tinada à criação de editores para programação visual, totalmente baseada em tecnologias web e
portável. Trata-se de uma ferramenta que executa do lado do cliente, funcionando na maioria
dos navegadores web e em dispositivos móveis ( BLOCKLYRESOURCE, 2015).
Blockly pode ser integrado a qualquer aplicação que ofereça um componente web e é ca-
paz de oferecer teste de unidade, possibilidade de tradução, tratamento de eventos e construção
de blocos customizáveis, permitindo inclusive mutabilidade. O processo de criação dos blocos
consiste em definir seu formato, campos e pontos de conexão e se necessário, modificadores,
o que pode ser realizado com o uso do Block Factory ou ainda da API JSON. Em seguida é
criado o gerador de código para que o novo bloco possa ser exportado para alguma linguagem
de programação.
Um exemplo tipico de definição de um bloco:
1 Blockly.Blocks[’text_length’] = {
2 init: function() {
3 this.setColour(160);
4 this.appendValueInput(’VALUE’)
5 .setCheck(’String’)
6 .appendField(’length of’);
7 this.setOutput(true, ’Number’);
8 this.setTooltip(’Returns number of
9 letters in the provided text.’);
10 this.setHelpUrl(’http: / / www.w3schools.com/
11 jsref/jsref_length_string.asp’);
12 }
13 };
Embora Blockly não seja escalável para grandes programas, pode ainda ser usado como
um editor de linguagens visuais para áreas específicas, apresentando elementos comuns a lin-
guagens de programação tais como funções, variáveis, arrays, checagem básica de tipos e afins.
Por ser uma ferramenta para criação de editores de linguagens visual, impossibilita que o usuá-
rio cometa erros de sintaxe ao fazer programas via Blockly.
A flexibilidade da ferramenta pode ser observada na utilização para criação de jogos,
aplicativos móveis para Android, programação web ou ainda como recurso educacional (BLOC-
KLYGAMES, 2015; APPINVENTOR, 2015; MARRON; WEISS; WIENER, 2012; SILVEIRA Jú-
12
NIOR et al., 2015).
2.3 Modelos matemáticos de simulação de culturas agrícolas
Neste projeto serão usados modelos matemáticos que simulam diversos processos eco-
fisiológicos de culturas Agrícolas. Em geral, estes modelos trabalham dentro de um ciclo diá-
rios, em função de variáveis meteorológicas que englobam temperatura, umidade do ar, radiação
solar, precipitação, nível de CO2 atmosférico, dentre outros, com base na localização geográ-
fica a ser simulada. Alguns modelos também utilizam condições do solo, que podem envolver
balanço hídrico e nível de nutrientes disponíveis e, por fim, o tipo de cultivar sendo simulada, no
caso como variáveis que descrevem como ocorre seu desenvolvimento (STRECK et al., 2015).
Os modelos que serão usados para estudo de caso em conjunto com a ferramenta desenvolvida
no projeto são o Simanihot, SoySim e DSSAT.
O Simanihot é um modelo matemático dinâmico baseado em processos (process-based
model). Foi projetado para trabalhar em ciclos diários e simula diversos processos eco-fisiológicos
da cultura da mandioca. O modelo foi desenvolvido pelo grupo Agrometeorológico da Univer-
sidade Federal de Santa Maria e é destinado a simular o crescimento, desenvolvimento e produ-
tividade da cultura em questão no estado do Rio Grande do Sul, Brasil. O modelo utiliza como
dados de entrada, as datas de plantio e de colheita, dados meteorológicos e balanço hídrico do
solo, sendo um programa disponibilizado de forma gratuita (SIMANIHOT, 2015).
Outro modelo usado neste projeto, o SoySim, simula o desenvolvimento da cultura de
soja e foi desenvolvido pela Universidade de Nebraska-Lincoln. Este modelo simula o po-
tencial de rendimento, assim como as necessidades de irrigação, sem limitação pela irrigação
e assumindo suplemento ideal de nutrientes e sem perdas de rendimento por influências do
ecossistema, tais como granizo, ou de outros meios, tais como envenenamento por nitritos ou
nitratos. O ciclo de simulação deste modelo também é diário (SOYSIM, 2015).
o DSSAT é um programa que engloba diversos modelos de simulação de culturas
agrícolas, num total de 42 culturas. Oferece suporte ao manejamento de solo, clima e culturas
assim como dados experimentais, por via também de utilitários e outros programas. Os modelos
disponíveis simulam o crescimento, desenvolvimento e potencial como uma função de condi-
ções agrometeorológicas, tendo sido usado tanto no refino de manejo, em fazendas ou para
análise de impacto climático sobre as culturas suportadas (DECISION SUPPORT SYSTEM
FOR AGROTECHNOLOGY TRANSFER , DSSAT).
13
3 DESENVOLVIMENTO
Na sequência, serão descritas as tarefas desenvolvidas para se chegar no objetivo pro-
posto por este trabalho. Na primeira etapa será realizada a concepção do software automati-
zador, onde serão analisados problemas de automação em softwares de simulação de culturas
agrícolas e soluções existentes para automatização de interfaces gráficas, levantando os requisi-
tos necessários para a solução dos problemas de automação destes softwares, dentro do objetivo
proposto. Após a concepção Será modelada uma solução, procurando compreender que compo-
nentes são necessários e por qual motivo eles necessitam ser criados. Finalmente será realizado
o desenvolvimento do software, verificando as diversas abordagens para criação dos componen-
tes, discutindo as escolhas realizadas apos verificação das abordagens possíveis.
3.1 Concepção
Nesta etapa serão apresentados casos de uso obtidos com três atores, e posteriormente,
uma análise com três ferramentas existentes para automação de tarefas em programas com
interface gráfica, o UiPath, o Sikuli e o Autoit, procurando embasar o objetivo deste projeto,
os requisitos da solução e as decisões tomadas durante a modelagem e desenvolvimento do
software.
3.1.1 Elaboração dos casos de uso
Com as reuniões realizadas semanalmente no primeiro mês, foram discutidos e coletados
três casos de uso com estudantes da área de agrometeorologia no Departamento de Fitotecnia
da UFSM, procurando entender as necessidades de automatização dos estudantes em cada um
dos modelos com o qual trabalham.
O primeiro caso de uso é referente as necessidades da Engenheira Agrônoma Amanda
thirza Lima, mestranda no programa de Pós-Graduação em Agronomia da UFSM, nas ativida-
des de seu projeto de dissertação para indicar um novo zoneamento agroclimático para a cultura
de mandioca no estado do Rio Grande do Sul utilizando o programa Simanihot, modelo de
simulação da cultura da mandioca.
No segundo caso de uso foi tratado o objetivo da Jossana Ceolin Cera, Meteorologista
e Doutora em Engenharia Agrícola pela Universidade Federal de Santa Maria, com objetivo
14
realizado durante seu doutorado de forma completamente manual, onde foi usado o modelo
SoySim para simular o crescimento, desenvolvimento e produtividade de Soja para o estado do
Rio Grande do sul.
O último caso de uso foi referente a tese de Cesar Augusto Fensterseifer, graduado em
Engenharia Ambiental, Mestre em engenharia civil e ambiental e atualmente aluno de doutorado
do programa de pós-graduação em engenharia agrícola da UFSM, que deseja gerar previsões de
safra de soja para auxiliar no planejamento agrícola do Estado do Rio grande do Sul.
Em todos os casos de uso as pré e pós condições são as mesmas, no caso, a ferramenta
deve iniciar em condição de realizar uma automatização e finalizar em um estado capaz de
iniciar novamente a mesma automatização. Os três casos de uso são descritos em ordem:
Caso de Uso 1: Automatização de simulações no modelo Simanihot para novo zonea-
mento agroclimático para a cultura de mandioca
breve descrição: Para o desenvolvimento da tarefa é preciso fazer muitas simulações
para que se possa indicar os melhores dias de plantio em uma série histórica de anos agrícolas.
Para que sejam realizadas essas indicações é necessário que sejam realizadas simulações diárias
da data de plantio de primeiro de julho a 31 de dezembro para todos os anos desde 1960 a 2015,
para 18 locais utilizando 4 cultivares; é necessário também fazer uma simulação para uma
cultivar, em uma única data de plantio, local e ano especifico.
Fluxo Principal:
1. Os seguintes campos são preenchidos, mas não variam: concentração de dióxido de car-
bono (CO2) 400 ppm, densidade de plantio 15625 plantas por hectare, simulação a partir
do plantio, data de colheita (15/06), modelo de balanço hídrico de Thornthwaite e Mather
e respectivamente neste modelo de balanço hídrico, a profundidade de maniva 8 cm e
profundidade máxima de raiz 30cm.
2. Será inserido um arquivo de entrada para cada local (Bagé, Bento Gonçalves, Bom Je-
sus, Caxias do Sul, Cruz Alta, Encruzilhado do Sul, Irai, Lagoa Vermelha, Passo Fundo,
Pelotas, Porto Alegre, Rio Grande, Santa Maria, Santa Vitória do Palmar, Santana do Li-
vramento, São Luiz Gonzaga, Torres, Uruguaiana). Para cada arquivo será utilizado um
tipo específico de solo e será selecionado o local específico.
15
3. As simulações serão realizadas para 3 cultivares, sendo elas FEPAGRO RS13, Estran-
geira e São José.
4. Para cada arquivo de entrada, serão realizadas simulações que variam de n = 1
ˇ
r de agosto
até 31 de dezembro, com variando de um em um dia.
5. A data de colheita não variará com as simulações, será sempre dia 15 de junho.
6. Depois de completar todos esses passo, finalmente clicará no botão SIMULAR.
Fluxo Secundário:
1. Nenhum
Fluxo de exceção:
1. Em caso de qualquer interação do usuário durante a tarefa de automação, pausar a simu-
lação e esperar que o usuário recomece a automação ou cancele.
2. No caso de encontrar algum alerta de campo preenchido incorretamente, encerrar a auto-
mação e envia o usuário para a pós condição.
Caso de Uso 2: Automação de simulações no modelo SoySim para simular o cresci-
mento, desenvolvimento e produtividade de Soja para o estado do Rio Grande do sul
breve descrição: Fazer simulações para 37 pontos espalhados no Rio Grande do Sul (37
arquivos de dados meteorológicos), com 120 anos de dados em cada arquivo, de 1980 a 2099,
utilizando 7 datas de semeadura (01/08, 01/09, 01/10, 01/11, 01/12, 01/01 e 01/02) e 3 grupos
de maturação (4.8, 5.5 e 6.0), em 2 cenários climáticos futuros. Dois conjuntos de dados com
37 arquivos de dados meteorológicos cada um. Dividindo cada um desses 37 arquivos em 3
arquivos com 45 anos de dados, pois o modelo SoySim não suporta fazer a simulação com um
arquivo de dados tão extenso.
Fluxo Principal:
1. Inserir um arquivo de entrada para cada ponto (2751 19602007, 2751 20062053, 2751
20522099, 2752 19602007, 2752 20062053, 2752 20522099 e assim por diante).
16
Figura 3.1: Fluxograma do caso de uso 1.
2. Realizar as simulações para os grupos de maturação (4.8, 5.5 e 6.0).
3. Para cada arquivo de entrada realizar simulações que variam de 01 de agosto até 01 de
fevereiro, iniciando na semeadura, de um em um mês
4. Modificar a densidade de população de plantas para 315.
5. Depois de preencher estes campos, clicar no botão run.
6. Copiar os dados a partir da linha 14 a 59 do arquivo de resultado TmpOut.txt e armazenar
todos em um resultado filtrando itens específicos e gerar um arquivo de resultado com
o mesmo.
Fluxo Secundário:
1. Reiniciar a automação alterando a automação para que a mesma não seja rodada na função
de multiple years mas sim seja rodada na função de single years, onde cada ano precisa
ser definido na interface.
2. Copiar a linha 35 do arquivo resultante TmpOut.txt e adicioná-la ao final de um arquivo
de resultado único.
17
Fluxo de exceção:
1. No caso de encontrar algum alerta de campo preenchido incorretamente, encerrar a auto-
mação e envia o usuário para a pós condição.
2. Caso o modelo apresente um alerta rodando no fluxo principal o programa deve passar
para o fluxo secundário
3. Caso o alerta seja recebido enquanto o modelo está no fluxo secundário, passar para o
ano seguinte da lista de anos da automação.
4. Em caso de qualquer interação do usuário durante a tarefa de automação, pausar a simu-
lação e esperar que o usuário recomece a automação ou cancele.
Figura 3.2: Fluxograma do caso de uso 2.
Caso de Uso 3: Automação de simulações no modelo DSSAT para gerar previsões de
safra de soja para auxiliar no planejamento agrícola do Estado do Rio grande do Sul
breve descrição: O RS é um dos Estados brasileiros que mais sente os efeitos dos
fenômenos El Nino e La Nina, e atualmente é o terceiro maior responsável pela produção de
soja do País. É necessário gerar previsões de safra de soja para auxiliar no planejamento agrícola
do Estado do Rio grande do Sul (RS). gerando várias simulações no modelo para diversas datas
de semeadura.
18
Fluxo Principal:
1. Abrir o DSSAT, esperar carregar e clicar em Crop Management Data. A partir dessa ação,
o programa XBuild inicializará, e o usuário deve então clicar em New (para começar a
criar um experimento).
2. Criar um nome inexistente para o experimento. Institute Code (SM para UFSM), Site
Code (RS se for dentro do RS), Year (2013), Experiment Number (99 datas de semeadura),
por exemplo. Lembrando que o usuário é livre para escolher a forma de preencher as
lacunas dessa etapa do experimento, de uma forma que o torne auto-explicativo. No
campo Crop (selecione Soybean). As demais lacunas podem ser preenchidas com -99.
3. Nessa etapa o usuário clica em Environment e depois em Fields. Aqui basicamente deve
ser informado qual a série meteorológica o experimento vai utilizar, se existe algum tipo
de drenagem e as características do solo daquela região. Ao rodar o modelo para ou-
tro local, o usuário deve adicionar mais um level e repetir o preenchimento com a série
meteorológica e as características do segundo local, e assim sucessivamente.
4. O usuário clica em Management e seleciona Cultivars, a tela sera redirecionada para
uma seção onde deve ser selecionada a cultivar ou as cultivares que serão utilizadas nas
rodadas do modelo. Lembrando que essas devem estar devidamente calibradas pois
caso contrário, o nome da cultivar não aparecera na lista de seleção.
5. Inserção da data ou datas de semeadura, data de emergência, o método utilizado, a forma
de distribuição das sementes, a densidade de sementes na semeadura, a densidade de
plantas na emergência, o espaçamento entre linhas adotado, a direção das linhas em rela-
ção ao Norte e a profundidade de semeadura utilizada para um ou vários experimentos.
Lembrando que se o experimento possui alguma característica diferente, esse deve ser
inserido como um Novo Level.
6. Determinar a data que o modelo vai começar a simulação do balanço hídrico ou de nutri-
entes no solo. É aconselhado começar o balanço hídrico no solo entre 20 e 30 dias antes
da data de semeadura, buscando uma simulação mais precisa das condições do solo na
hora da semeadura.
7. Selecionar os balanços que gostaria que o modelo realizasse em cada experimento. Aqui
19
pode ser ativado ou não o balanço hídrico, de nitrogênio entre outras. Esses detalhes
podem aumentar o desempenho das simulações.
8. Decidir os métodos que serão utilizados nos balanços que foram selecionados no passo
anterior. Se o balanço hídrico foi selecionado, aqui o usuário deve selecionar o método
que o modelo deve utilizar para as rodadas em cada experimento. Essa regra também vale
para os outros balanços que o usuário deseja que o modelo realize.
9. Caso o usuário tenha dados mais específicos ou tenha utilizado irrigação em algum dos
experimentos que deseja simular, essa é a etapa em que vai inserir as características do
manejo utilizado.
10. Seleciona as informações que serão exibidas no final das rodadas como: Crescimento de
massa seca diária, balanço hídrico....entre outros.
11. Caracterizar cada experimento, identificando cada experimento que vai utilizar a primeira
estação meteorológica por exemplo, ou o solo número 1 entre outras informações.
12. Após realizar essas etapas o usuário deve clicar no botão Refresh, que irá atualizar as
novas informações e posteriormente pode abrir o programa DSSAT e começar a rodar os
experimentos cadastrados.
Fluxo Secundário:
1. Nenhum
Fluxo de exceção:
1. No caso de encontrar algum alerta conhecido do modelo tais como alerta de temperatura
máxima menor que a mínima, encerrar a automação e envia o usuário para a pós condição.
2. Em caso de qualquer interação do usuário durante a tarefa de automação, pausar a simu-
lação e esperar que o usuário recomece a automação ou cancele.
20
3.1.2 Analise dos casos de uso em outras ferramentas de automação
Após a coleta dos casos de uso, foi analisado como outras ferramentas existentes atual-
mente, modelam os problemas observados nos casos de uso coletados, objetivando compreender
como e sob quais condições, estas ferramentas conseguem solucionar os casos de uso.
Dentre as ferramentas escolhidas, foram selecionados três programas de automação de
interfaces gráficas capazes de solucionar os casos de uso. Os três programas escolhidos foram
descritos na revisão bibliográfica deste projeto, sendo estes, UiPath, Sikuli e Autoit.
Como forma de avaliação adicional do quanto estas ferramentas se mostram acessíveis
aos domínios de conhecimento do usuário, foi proposto a um dos atores dos casos de uso, que
este tentasse utilizar as mesmas ferramentas de automação descritas na revisão literária, para
resolver seu caso de uso. Descrevendo a experiência de forma objetiva, em prós e contras,
analisando se foi obtido sucesso ou não e onde os problemas responsáveis pelas falhas se origi-
naram, caso encontrado algum.
21
UiPath:
Prós: O programa permite virtualmente a realização de qualquer tarefa por meio da cons-
trução de um fluxograma, com diversos elementos, vários deles autoexplicativos, tais como
as regras de interação de clique e digitação na interface dos modelos matemáticos. Fornece
lógica suficiente para as repetições e iterações necessárias nos casos de uso, também permite
mover ou renomear arquivos para que as rodadas não se sobrescrevam no caso 2.
Contras: O programa é muito complexo, fator especialmente observado ao tentar modelar
regras para o tratamento de erros no caso 1 e 2, contem muitas opções, elementos carregados
e complexos e poucas funções realmente genéricas. Em outro exemplo de complexidade, al-
guns elementos envolvem expressões VisualBasic. Depende da chamada de métodos externos
ao programa para tarefas não contempladas pelos elementos de fluxograma, fator necessário
no parsing de valores em arquivos necessários para o caso 2, o que envolve métodos tra-
dicionais de automação, com linguagens de programação convencionais, podendo recorrer
inclusive ao powershell.
Sikuli:
Prós: O programa é fácil de entender com elementos autoexplicativos e não muito comple-
xos, é capaz de realizar as tarefas básicas tais como interagir com a interface do modelo e
esperar por eventos.
Contras: Para os casos de uso, os elementos visuais presentes não são suficientes e não con-
templam repetições, trabalhar com arquivos, tratar erros, dentre outros, tornando necessário
que o usuários recorra a linguagem Python para realizar a automação.
AutoIt
Prós: Novamente um programa capaz de realizar virtualmente qualquer tarefa. Apesar de sua
abordagem bastante tradicional de programação em texto, possui uma biblioteca bem ampla
de funcionalidades.
Contras: O programa é totalmente dependente de linguagem script tipo BASIC própria, sem
nenhum elemento visual ou autoexplicativo. A automação se torna um desafio possivelmente
tão grande quanto o problema original, que o usuário precisa conhecer com certa profun-
didade a linguagem, o programa e as bibliotecas do AutoIt.
Analise do caso de uso 2 realizada pelo autor de forma direta nos 3 programas de auto-
mação sugeridos sem intervenção de terceiros ou qualquer pessoa do domínio da área:
22
Caso de uso 2 Analisado pelo ator
Automação de simulações no modelo SoySim para simular o crescimento, desenvolvimento
e produtividade de Soja para o estado do Rio Grande do sul.
UiPath:
Prós: Conseguiu fazer com que o software rodasse o SoySim para SingleYear e LongTerm-
Run. Uma rodada sozinha.
Contras: Não conseguiu inserir um loop para que múltiplas rodadas fossem feitas, também
não conseguiu fazer com que o programa mudasse os arquivos de entrada automaticamente.
Além disso, não conseguiu fazer com que o programa entendesse a janela de erro do SoySim.
Sikuli:
Prós: consegui montar o scrit que é no mesmo formato do UiPath (visual).
Contras: Na hora de rodar, o programa apresentou um erro que o ator não consegue inter-
pretar, erro apresentado na figura 3.3. Desistiu da ferramenta devido ao erro.
AutoIt
O ator não conseguiu compreender minimamente como a ferramenta funciona, foi capaz
de perceber que o programa usa código textual para automatizar as tarefas mas por não ter
profundo contato com linguagens de programação ou BASIC, não foi capaz de encontrar uma
solução intuitivamente ou em tempo hábil no manual do programa. Desistiu da ferramenta
devido à dificuldade.
Figura 3.3: Erro obtido pelo autor no programa Sikuli.
Observando as informações obtidas ao analisar os casos de uso com outras ferramentas
de automação, foram encontrados alguns pontos relevantes para a Proposta do projeto.
1. Linguagens de programação tradicional não contribuem para os atores solucionarem seus
23
problemas e inclusive dificultam a obtenção de uma solução em alguns casos.
2. Apesar de possibilitar a solução, teoricamente, de qualquer problema inclusive fora da
automação de interfaces gráficas, linguagens de programação tradicional são desnecessa-
riamente complexas para os atores e inclusive, para o problema deste projeto, aumentaram
as duvidas dos atores e problemas que eles precisavam considerar durante a obtenção de
uma solução, tal como a validade sintática de suas soluções assim como coleta de infor-
mações em outras fontes com relação a vocábulos e semântica da linguagem.
3. Os momentos em que os atores mais se beneficiaram das ferramentas analisadas foi
quando as mesmas ofereceram, componentes sucintos e autoexplicativos, ou seja, que
descreviam o que fazem, como usá-los e como não usá-los.
4. O segundo momento em que os atores mais se beneficiaram das ferramentas analisadas
foi quando os componentes oferecidos interagiam com os atores, impedindo maneiras
incorretas de seu uso ou explicitando o uso correto por meio de diversas simbologias tais
como o encaixe perfeito entre os elementos, dentre outros.
5. O elemento-chave para os atores residiu na capacidade ou não da ferramenta em explicar
o que se pode fazer ou não, tomando para algumas tarefas que exigem atenção, como a
analise em algum nível da validade da solução.
3.1.3 Coleta dos requisitos funcionais
Com base nas informações obtidas durante a analise prévia do problema, dos casos
de uso, analise de ferramentas existentes, assim como discussão com os atores envolvidos,
surgiram ideias de funcionalidades, das quais foram selecionados alguns requisitos funcionais
mínimos para se chegar ao objetivo deste projeto assim como a solução dos problemas principais
nos casos de uso.
1. Deve ser possível executar, salvar ou carregar automações construídas pelo ator de forma
que se possa reutilizar estas automações, construídas anteriormente no programa. Tam-
bém é preciso que seja possível descartar a automação.
2. Dois elementos, um capaz de executar a ação de clicar uma vez em uma área da tela e
outro capaz de executar a ação de clicar duas vezes em uma área da tela; o ator deve
24
ser capaz de escolher a área da tela para cada instância do elemento e o elemento deve
representar a área onde irá realizar a ação.
3. Um elemento capaz de esperar por uma alteração na tela ou evento que indique que a
automatização pode prosseguir para as próximas tarefas definidas pelo ator.
4. Um elemento capaz de digitar textos nos campos do programa a ser automatizado, como
se fosse o usuário digitando.
5. Elementos complementares que consigam expressar a lógica, condições, repetições ações
e valores tais como números e textos.
6. Um elemento capaz de ler ou gravar um arquivo de texto de forma que se possa alterar
o texto lido ou que se possa apenas copiar o arquivo para outro lugar, podendo mudar o
nome.
7. Um elemento que permita tomar decisões que alterem o fluxo de automação.
8. Uma forma de pausar ou continuar a simulação.
3.2 Modelagem
Para que um software possa automatizar outro software com interface gráfica, é neces-
sário que o software que realiza a automação possa enviar informação para o software a ser
automatizado assim como sua interface gráfica. Analogamente, é preciso que o software auto-
matizador possa receber informação do software a ser automatizado.
Possibilitar que o software automatizador envie e receba informações para o software
a ser automatizado inicialmente envolve estabelecer quais são as possíveis entradas e saídas
de informação do software a ser automatizado sabendo que este desconhece a existência do
automatizador, para em seguida, definirmos as entradas e saídas necessárias para que o software
automatizador possa estabelecer a comunicação necessária com o software a ser automatizado
por meio de suas entradas e saídas.
Após conhecermos as entradas e saídas do software a ser automatizado é possível mo-
delar as entradas e saídas do software automatizador, visando enviar e receber informações
do software que queremos automatizar. Ao mesmo tempo, será modelada a entrada, saída e os
componentes internos que dão ao software automatizador, as condições necessárias para realizar
25
as funcionalidades concebidas durante a coleta de requisitos, observando também, a proposta
deste projeto e conhecimentos obtidos analisando outras ferramentas existentes durante o es-
tudo dos casos de uso. A entrada e saída precisará também ser modelada considerando como
o ator ou usuário irá interagir com o software automatizador para que este realize a automação
necessária.
3.2.1 Entradas e saídas do software a ser autoamatizado
Para definir as entradas e saidas do software a ser automadizado, se interagiu e observou
os modelos matemáticos agrícolas de simulação de culturas agrícolas escolhidos para serem
automatidados neste projeto. Durante as observações, considerou-se quais eram os elementos
com com que se podia interagir assim, forma de interação e resultados observados, a figura3.4
descreve como os modelos recebem e produzem as entradas e saídas. Observou-se que os
modelos podem receber dois tipos de entrada e produzir dois tipos de saída:
entradas:
ações: Interações que resultassem em algum evento ou resposta do software.
dados: fornecer de informações, arquivos, preencher campos, dentre outro, podendo
ou não serem precedidos de uma ação.
saídas:
eventos: Eventos ou respostas decorrentes da interação com o software que buscam
informar o usuário de alguma condição atingida no software.
dados: O produto final esperado pelo usuário, decorrente da realização de uma simu-
lação.
Como é possível observar na figura3.4, as ações correspondem a interações de entrada
que podem resultar em alguma mudança da interface e ou do software, logo, produzem eventos
ou dados como saída, podendo inclusive produzir ambos.
Os dados quando considerados como entrada, podem ser inseridos de duas formas; após
algum evento, que indique para o usuário que o mesmo pode colocar os dados no componente
desejado, como em um textfield, onde o usuário pode inserir diversos valores tal como números,
texto ou a localização de arquivos; ou ainda podem ser inseridos automáticamente, caso o pro-
grama sempre procure por arquivos em algum local específico. Em geral, inserir dados resulta
26
Figura 3.4: Descrição das entradas e saídas do software a ser automatizado, a grande ceta verde
mostra que é possível inserir arquivos no software, a vermelha, que é possível obter arquivos do
software, e a laranja indica que, não somente mensagens, mas qualquer componente da interface
pode representar um evento.
em algum evento observável.
Quando consideramos os eventos de saída, estas resultam, ou de alguma entrada de
dados automática, ou de alguma ação. Os eventos procuram informar o usuário de alguma con-
dição satisfeita, como por exemplo, sucesso na inserção de um arquivo, ou de algum problema
que deve ser observado, como por exemplo, algum campo preenchido incorretamente, ou que
por exemplo, um elemento recebeu o evento e espera pela inserção de dados.
Finalmente, considerando os dados de saída, podem ser observados duas formas de
saída, dados que são apresentados em componentes da interface gráfica, no caso dos modelos
observados, podemos citar componentes como tabelas e gráficos; ou como resultado em arqui-
vos, que no caso dos modelos observados, são arquivos de texto. Os dados de saída podem ser
gerados tanto por eventos como automáticamente; quando gerados automáticamente, se deve
ao fato de que o modelo tem a capacidade de acessar e carregar automaticamente resultados
produzidos em algum momento no passado.
Uma ultima observação que podemos fazer é que, do ponto de vista dos modelos obser-
vados, e até mesmo de uma grande parte dos softwares com interface gráfica, podemos observar
que todas as saídas e inclusive a entrada de dados, em algum momento, são produto de alguma
ação, como por exemplo ações externas ao software que não são consideradas na figura3.4,
como o ato de executar o software a ser automatizado, ação realizada no sistema operacional.
Logo, eu não preciso ser capaz de interagir com o software mas também com o sistema
27
operacional em algum nível.
3.2.2 Modelagem do software Automatizador
Figura 3.5: Erro obtido pelo autor no programa Sikuli.
3.3 Desenvolvimento do software
3.3.1 Interação entre automatizador e software a ser automatizado
3.3.2 Construção de automatizações
3.3.3 Codificação
O desenvolvimento do software foi dividido em 3 problemas que definem as principais
necessidades do software para que seja possível obter as funcionalidades previstas durante a
discussão dos requisitos funcionais.
O primeiro problema a ser solucionado foi a utilização da biblioteca Blockly em uma
aplicação local com o objetivo de ter maior acesso aos recursos do sistema.
Em seguida foi solucionado como realizar a interação com o sistema operacional e as
entradas de baixo nível tais como mouse e teclado, assim como um método para analisar e
pesquisar em imagens para encontrar os locais selecionados pelo usuário onde clicar.
Como escopo foram delimitados alguns pré-requisitos necessários para utilizar a solução
proposta neste trabalho, onde, o software deve ser uma aplicação desenvolvida usando Java e
28
JavaScript.
3.3.4 Blockly em uma aplicação Java
Em um primeiro momento, com o objetivo de rodar o Blockly, uma biblioteca JavaScript
100% client side dependente de um ambiente web, em uma aplicação java, optou-se por uma
solução que envolve uma aplicação JavaFX com um cliente web embutido, descrita de forma
geral na imagem 3.6.
Figura 3.6: Estrutura geral da solução.
O software ao iniciar carrega a página da aplicação web desenvolvida com base na bibli-
oteca Blockly em uma instância da classe WebEngine, contida na plataforma JavaFX, sendo
que esta instância pertencente a um objeto da classe WebView também oriunda da plataforma
JavaFX, responsável pela gestão e renderização da página web na interface gráfica de uma apli-
cação JavaFX.
Foi utilizada a funcionalidade LiveConnect, presente na maioria dos navegadores web,
que permite a comunicação entre o navegador e aplicativos java para conectar o software e a
aplicação web. Foi desenvolvida a classe JavascriptMsgr com o objetivo de estabelecer os
métodos de comunicação entre a aplicação web e o software, contendo uma referência para o
objeto instanciado da classe javafx.scene.web.WebEngine com o qual cria um objeto
netscape.javascript.JSObject que torna a classe JavascriptMsgr visível para
a aplicação web.
29
A classe JavascriptMsgr trata tanto as mensagens vindas da aplicação web como as
mensagens enviadas do software, a imagem 3.7 apresenta dois exemplos de métodos presentes
na classe JavascriptMsgr em trechos distintos
1
, onde o primeiro envia uma mensagem
para a aplicação web e o segundo recebe uma mensagem.
1 / / método que envia uma String contendo o arquivo XML gerado na ultima vez em que foi
2 / / salvo a blockly.mainWorkspace
3
4 public void loadBlocks(String xml) {
5 com.sun.javafx.application.PlatformImpl.runAndWait(() ->{
6 String escaped = StringEscapeUtils.escapeEcmaScript(xml);
7 engine.executeScript("loadBlocks(\""+ escaped +"\")");
8 });
9 }
10
11 / / método que recebe um pedido para esperar enquanto não localizar uma imagem na
12 / / pasta raiz, recebe um endereço relativo na pasta raiz do software e um valor
13 / / de intervalo em milissegundos que deve esperar a cada procura sem sucesso
14 public void waitImg (String imgSrc, int milisec){
15 try {
16 BufferedImage target = null;
17 target = ImageIO.read(new File(imgSrc.substring(3)));
18 BufferedImage screenshot =
19 robot.createScreenCapture(primaryScreenBounds);
20 ImageSearch is = new ImageSearch(target);
21
22 while(is.search(screenshot)[0] == -1){
23 screenshot = robot.createScreenCapture(primaryScreenBounds);
24 System.out.println("tried");
25 Thread.sleep(milisec);
26 }
27 System.out.println("match!");
28 } catch (IOException | InterruptedException e) {
29 e.printStackTrace();
30 }
31 }
Figura 3.7: Dois métodos da classe mediadora da comunicação entre a aplicação web e o soft-
ware
A classe possui diversos métodos que estendem as funcionalidades da aplicação web
e permitem ao software utilizar a biblioteca blockly para fornecer a biblioteca visual, gerar e
executar código.
3.3.5 Interação e pesquisa por regiões na tela do sistema operacional
A interação com o Sistema operacional é realizada por instâncias da classe java.awt.Robot
capaz de gerar eventos de sistema, nativos. Apesar de ter sido desenvolvida com o objetivo prin-
cipal de realizar testes automatizados e aplicações autoexecutáveis, por ser capaz de manipular
mouse e teclado em nível de sistema, pode ser utilizada para qualquer tarefa que busque auto-
matizar o controle do sistema operacional.
1
código completo disponível em https://github.com/RomuloPBenedetti/TCC/tree/master/Software/src/
30
Para encontrar as áreas a serem clicadas ou regiões a serem observadas na espera de
uma mudança, foi desenvolvida a classe ImageSearch com uma solução própria de pesquisa
otimizada para imagens, que analisa uma imagem capturada da tela do sistema em busca de
referências exatas das áreas escolhidas pelos usuários.
Diversas outras soluções foram analisadas como a biblioteca OpenCV (OPENCV, 2015)
ou ainda o framework brasileiro de processamento de imagens em Java, Marvin (ARCHANJO;
ANDRIJAUSKAS; MUÑOZ, 2008). Porém outras soluções traziam diversos problemas que
não se justificavam, variando da necessidade de mais bibliotecas, adaptação a uma abordagem
mais complicada e distante da necessidade do projeto ou ainda limitações em termos de plata-
formas.
A abordagem é descrita na figura 3.8, se trata de extrair da área selecionada pelo usuário,
dois pixels, um com o maior valor de cor RGB dentre todos e outro com o menor valor dentre
todos, assim como a distância ’x’ e ’y’ destes dois pixels da origem. Por questões de otimização
as cores nas imagens são analisadas como se fossem inteiros absolutos de 32 bits.
Posteriormente percorre quase todos os pixels da imagem capturada da tela do sistma,
de x = 0 até x = (larguraCaptura - larguraArea), usando a posição em que se encontra como
âncora para verificar nas posições salvas dos pixels extraídos da área são iguais aos pixels na
posição da imagem.
Caso os 2 pixels sejam iguais, inicia-se uma análise de uma malha esparsa de pixels
na área, onde é somado a diferença dos pixels da imagem extraída pelo usuário e a imagem
capturada da tela, caso a diferença no final for zero, significa que foi encontrado uma área na
imagem capturada igual à imagem da área que o usuário escolheu e neste caso a função retorna
a posição ’x’ ’y’ da âncora.
Os métodos principais da classe ImageSearch
2
, podem ser observados na imagem
3.9.
O método StoreTarget percorre a imagem que o usuário selecionou para ser clicada
ou analisada e compara o valor de cada pixel com variáveis auxiliares, onde posteriormente
sobrescreve o valor destas variáveis se o pixel for realmente um valor maior ou menor do que
os considerados anteriormente.
o método search procura pelo máximo ou mínimo na imagem capturada pelo soft-
ware, quando encontra a área que contem nas mesmas posições o valor máximo e mínimo,
2
código completo disponível em https://github.com/RomuloPBenedetti/TCC/tree/master/Software/src/
31
Figura 3.8: descrição visual da tarefa realizada pela classe ImageSearch.
analisa a área um pixel a cada três, caso a soma de todas as diferenças da área de um valor 0
todas as threads são paradas e a posição do pixel âncora ou origem da área é retornado. A tarefa
também é dividia entre os núcleos do processador do usuário para obter melhor performance e
o método apenas retorna quando o todas as threads iniciadas pela pesquisa terminarem.
3.3.6 modelagem das funcionalidades no softwares
A interface do software foi desenvolvida para ser o mais simples e limpa possível com o
objetivo de diminuir duvidas ou confusão dos usuários, existem, além do botão nativo de lixeira,
mais três botões, um para executar a simulação, um para carregar um quebra-cabeças que tenha
sido salvo e outro para salvar um quebra-cabeças atualmente no software. O programa utiliza o
único formato de armazenamento em arquivo disponível na biblioteca Blockly, a linguagem de
marcação XML. É possível ver a interface na figura 3.10.
Para fornecer as funcionalidades foram definidos quatro blocos que expressam funcio-
nalidades fundamentais para a automatização, dois blocos que expressam a habilidade de clicar
em algum lugar da interface, um para clique duplo e outro para clique único, também, um bloco
que permite esperar por algum evento visual, para que seja possível esperar a finalização do
processamento dos modelos, e por último um bloco que permite digitar texto na entrada de
texto do sistema operacional.
É possível observar os blocos na imagem 3.11 e a descrição formal em JavaScript destes
blocos na figura 3.123.13
3
.
Como é possível ver o bloco Image_Wait e os blocos que representam as ações de cli-
que de mouse, click_doble_special e click_single_special utilizam um campo
próprio chamado FieldImageButton, desenvolvido observando-se o campo original pre-
3
código completo disponível em https://github.com/RomuloPBenedetti/TCC/tree/master/Software/src/
32
1
2 public final void storeTarget(BufferedImage t) {
3 this.t = t; int rgb; tWidth = t.getWidth(); tHeight = t.getHeight();
4 for(int x = 0; x < tWidth; x++) {
5 for (int y = 0; y < tHeight; y++) {
6 rgb = t.getRGB(x, y);
7 if (Integer.compareUnsigned(rgb, max)>0) { max = rgb; maxX = x;
maxY = y; }
8 if (Integer.compareUnsigned(rgb, max)<0) { min = rgb; minX = x;
minY = y; }
9 }
10 }
11 }
12
13 public final int[] search(BufferedImage i) {
14
15 int iWidth, iHeight, point[] = new int[2];
16 point[0] = -1; point[1] = -1;
17 int startX[] = new int[cores], endX[] = new int[cores];
18 int startY[] = new int[cores], endY[] = new int[cores];
19
20 iWidth = i.getWidth()-tWidth; iHeight = i.getHeight()-tHeight;
21 ExecutorService executor = Executors.newFixedThreadPool(cores);
22
23 for (int q = 0 ; q < cores ; q++){
24 startX[q] = (iWidth/cores)
*
q; startY[q] = 0;
25 endX[q] = (iWidth/cores)
*
(q+1); endY[q] = iHeight;
26 int fQuad = q;
27
28 executor.execute(() -> {
29 Thread.currentThread().setName("thread" + fQuad);
30 int difference = 100; int rgbC;
31 for (int x = startX[fQuad]; x < endX[fQuad]; x++) {
32 for (int y = startY[fQuad]; y < endY[fQuad]; y++) {
33 rgbC = i.getRGB(x + maxX, y + maxY);
34 if (rgbC == max) {
35 rgbC = i.getRGB(x + minX, y + minY);
36 if (rgbC == min) {
37 difference = 0;
38 for (int ty = 0; ty < tHeight; ty = ty +3) {
39 for (int tx = 0; tx < tWidth; tx = tx +3) {
40 difference += t.getRGB(tx, ty) -
i.getRGB(x+tx, y+ty);
41 }
42 }
43 if (difference == 0) {
44 point[0] = x; point[1] = y;
45 executor.shutdownNow();
46 }
47 }
48 }
49 if (difference == 0) break;
50 }
51 if (difference == 0) break;
52 }
53 });
54 }
55 try {
56 executor.awaitTermination(1, TimeUnit.SECONDS);
57 } catch (InterruptedException e) {
58 e.printStackTrace();
59 }
60 return point;
61 }
Figura 3.9: Métodos que analisam a imagem da área e a imagem capturada da tela do sistema
sente na biblioteca Blockly field_image
4
, este campo adiciona a imagem um eventListenner
4
o código desta classe pode ser encontrado em https://github.com/google/blockly/
33
Figura 3.10: Tela inicial do software desenvolvido
Figura 3.11: Blocos construídos para as operações de automação
que ao ser clicado envia uma mensagem que início a tarefa de captura de tela no software, que
ao ser terminada pelo usuário, envia uma mensagem contendo o caminho da imagem da área
selecionada pelo usuário que deve sofrer a ação do bloco junto com suas dimensões. Por sua
vez a aplicação web atualiza a imagem do bloco para representar a área que o usuário escolheu.
Toda a tarefa é mantida coêsa transferindo junto com estas mensagens o ID único que a
34
própria biblioteca Blockly gera para cada bloco assim tanto a aplicação web como o software
sempre sabem para que bloco é cada mensagem. Por questões de flexibilidade e simplicidade
foi decidido utilizar a linguagem JavaScript por questões de simplicidade que é uma das
linguagens nativas do software e disponível para os outros blocos da biblioteca por padrão já.
Quando o usuário clica no botão para executar o modelo no software, é enviado uma
mensagem para a aplicação web, pedindo que para que a biblioteca Blockly monte o código
com base no quebra-cabeça montado e por fim, execute o código com a função eval.
Como é possível observar, os geradores de código foram construídos para realizar cha-
madas no no software java e portanto, a aplicação web fica responsável apenas pela montagem
da lógica que guia a execução das tarefas tais como construção de repetições ou definições de
valores a serem enviados junto as mensagens para que o software as realize. É possível ver um
exemplo do código gerado por um conjunto de blocos nas figuras 3.14.3.15.
35
1 Blockly.Blocks[’click_single_special’] = {
2 init: function() {
3 this.appendDummyInput("imageInput")
4 .appendField("clicar uma vez em:")
5 .appendField(new
Blockly.FieldImageButton("../images/icons/clickBlack.png",
30, 30, "", imageButtonEvent), "FieldImageButton");
6 this.setPreviousStatement(true, null);
7 this.setNextStatement(true, null);
8 this.setColour(60);
9 this.setTooltip(’Procura na sua tela pela região que a imagem
representa e clica no centro uma veze, para escolher, clique na
imagem branca do bloco, va ao local desejado aperte ctrl+shift+c,
selecione onnde clicar com o mouse e aperte enter.’);
10 }
11 };
12
13 Blockly.Blocks[’click_doble_special’] = {
14 init: function() {
15 this.appendDummyInput("imageInput")
16 .appendField("clicar duas vezes em:")
17 .appendField(new
Blockly.FieldImageButton("../images/icons/clickBlack.png",
30, 30, "", imageButtonEvent), "FieldImageButton");
18 this.setPreviousStatement(true, null);
19 this.setNextStatement(true, null);
20 this.setColour(60);
21 this.setTooltip(’Procura na sua tela pela região que a imagem
representa e clica no centro duas vezes, para escolher, clique na
imagem branca do bloco, va ao local desejado aperte ctrl+shift+c,
selecione onnde clicar com o mouse e aperte enter.’);
22 console.log(this.id);
23 }
24 };
25
26 Blockly.Blocks[’text_typer’] = {
27 init: function() {
28 this.appendDummyInput("textToType")
29 .appendField("digitar:")
30 .appendField(new Blockly.FieldTextInput("texto"), "text");
31 this.setPreviousStatement(true, null);
32 this.setNextStatement(true, null);
33 this.setColour(60);
34 this.setTooltip(’’);
35 this.setHelpUrl(’http: / / www.example.com/’);
36 }
37 };
38
39 Blockly.Blocks[’Image_Wait’] = {
40 init: function() {
41 this.appendDummyInput("imageInput")
42 .appendField("esperar enquanto não encontrar:")
43 .appendField(new
Blockly.FieldImageButton("../images/icons/clickBlack.png",
30, 30, "", imageButtonEvent), "FieldImageButton");
44 this.appendValueInput("miliToWait")
45 .setCheck("Number")
46 .setAlign(Blockly.ALIGN_RIGHT)
47 .appendField("procurando a cada:");
48 this.appendDummyInput()
49 .appendField("milisegundos");
50 this.setInputsInline(true);
51 this.setPreviousStatement(true, null);
52 this.setNextStatement(true, null);
53 this.setColour(60);
54 this.setTooltip(’para escolher por que imagem esperar, clique na
imagem branca do bloco, va ao local desejado aperte ctrl+shift+c,
selecione onnde clicar com o mouse e aperte enter.’);
55 this.setHelpUrl(’http: / / www.example.com/’);
56 }
57 };
Figura 3.12: Descrição dos blocos na aplicação web e seus respectivos geradores de código
36
1 Blockly.JavaScript[’click_doble_special’] = function(block) {
2 src =
(block.getFieldValue(’FieldImageButton’)).replaceAll("\\\\","\\\\");
3 running = if (running) {\n’;
4 calling = running = java.clickIn(\"’ + src + ’\",’ + 2 + ’);\n’;
5 end = ’}\n’;
6 var code = running + calling + end;
7 return code;
8 };
9
10 Blockly.JavaScript[’click_single_special’] = function(block) {
11 src =
(block.getFieldValue(’FieldImageButton’)).replaceAll("\\\\","\\\\");
12 running = ’if (running) {\n’;
13 calling = "java.clickIn(\"" + src + ’\",’ + 1 + ’);\n’;
14 end = ’}\n’;
15 var code = running + calling + end;
16 return code;
17 };
18
19 Blockly.JavaScript[’text_typer’] = function(block) {
20 text = block.getFieldValue(’text’);
21 running = ’if (running) {\n’;
22 calling = " running = java.type(\"" + text + ’\");\n’;
23 end = ’}\n’;
24 var code = running + calling + end;
25 return code;
26 };
27
28 Blockly.JavaScript[’Image_Wait’] = function(block) {
29 src =
(block.getFieldValue(’FieldImageButton’)).replaceAll("\\\\","\\\\");
30 milisec = Blockly.JavaScript.valueToCode(block, ’miliToWait’,
Blockly.JavaScript.ORDER_ATOMIC) || ’0’
31 running = ’if (running) {\n’;
32 calling = java.waitImg(\"’ + src + ’\", ’+ milisec + ’);\n’;
33 end = ’}\n’;
34 var code = running + calling + end;
35 return code;
36 };
Figura 3.13: Geradores de código java dos blocos construidos
Figura 3.14: Exemplo de um quebra-cabeça
37
1 var running = true; var dias;
2
3 for (dias = 1; dias <= 31; dias += 3) {
4 for (var count = 0; count < 10; count++) {
5 if (running) {
6 java.clickIn("../images/icons/clickBlack.png",1);
7 }
8 if (running) {
9 running = java.type("digitar alguma coisa");
10 }
11 if (running) {
12 java.waitImg("../images/icons/clickBlack.png", 200);
13 }
14 }
15 }
Figura 3.15: Exemplo do código gerado por este quebra-cabeça
38
4 RESULTADOS
4.1 Validando solução com os casos de teste
Com as funcionalidades desenvolvidas no software não é possível solucionar todas as
questões desenvolvidas nos casos de teste dos 3 modelos Porem é possível solucionar em geral
o problema dos modelos projetando o quebra-cabeças levando em consideração as limitações
do software.
Algumas limitações principais encontradas ao modelar um quebra-cabeças para os casos
de teste coletados foram:
O software não é capaz de suavizar a criticidade com a qual procura os campos a serem
clicados, logo qualquer diferença torna impossível para o software localizar o campo
novamente.
O software não é capaz de se deslocar pela interface do sistema operacional, ir para a área
de trabalho ou navegar entre as janelas abertas do sistema.
O software não é capaz de editar arquivos de texto. Embora possua diversas capacidades
para processar textos dentre seus blocos, não ha nenhum bloco capaz de abrir um arquivo
armazenado em alguma pasta do sistema ou ainda ler texto da tela.
Apesar de ser capaz de esperar por mudanças gráficas na tela, o software não é capaz de
tomar decisões lógicas na ocorrência de uma mudança gráfica, habilidade relevante para
o tratamento de erros ou seguimento de múltiplos fluxos.
Dentre outras limitações não fundamentais, esta o fato de que o software não é capaz de
pausar ou reiniciar simulações em andamento, assim como também não ha feedback visual do
software quando o mesmo finaliza a tarefa ou encontra algum erro.
4.1.1 Simanihot
Foi validada apenas a abstração lógica da linguagem visual modelando um quebra-
cabeças para o caso de uso do modelo Simanihot onde todos os problemas fundamentais para a
solução do problema proposto no caso de uso são solucionados dentro da lógica disponibilizada
pelo conjunto de peças do software, como é possível ver na figura 4.1.
39
Em especial, é necessário configurar o quebra-cabeças para fechar e reabrir a aplicação,
que o software não possibilita definir um nível de similaridade das áreas a serem clicadas,
esperando uma similaridade exata, o que não ocorre de simulação em simulação, que a cada
simulação o texto que se encontra nos campos de texto é diferente do anterior.
Figura 4.1: Exemplo de um quebra-cabeça
40
5 CONCLUSÃO
A proposta inicial deste trabalho consistia principalmente em apresentar uma solução de
automação de interfaces gráficas de forma simplificada com base na biblioteca de programação
visual Blockly dentro do contexto de modelos de simulação de culturas agrícolas. Entretanto
o resultado final desta pesquisa trata-se não de uma solução total dos problemas apresentados,
mas de um software que oferece a possibilidade de automatização de alguns problemas com um
escopo não tão grande como o dos problemas propostos, com base nas conclusões tomada du-
rante o desenvolvimento, a partir dos percalços e da análise constante da amplitude da proposta
e das necessidades durante a validação das abordagens em questão.
Como contribuição este trabalho apresentou uma abordagem diferenciada na programa-
ção de tarefas automatizadas expondo de forma mais simplificada lógica comum em linguagens
de programação e script tradicionais, fornecendo uma ferramenta que pode descrever de forma
muito flexível interações com a interface gráfica e permitindo em algum nível realizar a automa-
tização de parte das tarefas maçantes presentes na interação com interfaces gráficas de modelos
matemáticos de simulação de culturas agrícolas mais simples.
A lista a seguir, não exaustiva, expõe em ordem de relevância, uma lista de algumas
melhorias que poderiam ser incorporadas em uma nova versão deste projeto:
Tratar arquivos com conteúdo de texto, permitindo copiar arquivos para outros locais,
criar arquivos com novas informações, renomeá-los e processar e extrair informações
destes textos.
Refinar a forma com a qual o programa localiza e clica nos elementos gráficos, seja
pela adição de procura por similaridades e áreas não exatas, ou por novos métodos para
definição da área onde se deve clicar.
Expandir a interação com o sistema operacional de forma que o software possa procurar
dentre diversas janelas e na área de trabalho.
Fornecer feedback visual ao finalizar automatizações ou receber erros durante a execução
de uma automatização.
Obter uma forma mais eficiente de captura de tela que a captura de tela realizada pela
classe Robot além de lenta pode produzir artefatos e não capturar alguns elementos
41
dinâmicos de alguns programas.
Oferecer blocos que simplifiquem elementos lógicos presentes na biblioteca Blockly
permitindo a formulação de quebra-cabeças de automatização mais simples.
Refinar os detalhes em geral da aplicação como salvamento e carregamento de quebra-
cabeças de forma que sejam salvas também as imagens pré selecionadas, fornecimento
de configurações para troca de idioma e possibilidade de pausar, continuar e reiniciar
quebra-cabeças.
42
REFERÊNCIAS
APPINVENTOR. Accessed:2016-02-19, http://appinventor.mit.edu/.
ARCHANJO, G.; ANDRIJAUSKAS, F.; MUÑOZ, D. Marvin–A Tool for Image Processing
Algorithm Development. Technical Posters Proceedings of XXI Brazilian Symposium of
Computer Graphics and Image Processing, [S.l.], v.1, n.1, p.5–6, 2008.
AUTOIT. Accessed: 2016-02-19, https://www.autoitscript.com/site/
autoit/.
AUTOMATOR. Accessed: 2016-02-19, https://developer.apple.com/
library/mac/documentation/AppleApplications/Conceptual/
AutomatorConcepts/Automator.html.
BARRY, E. J.; KEMERER, C. F.; SLAUGHTER, S. A. How software process automation
affects software evolution: a longitudinal empirical analysis. JOURNAL OF SOFTWARE
MAINTENANCE AND EVOLUTION: RESEARCH AND PRAC, [S.l.], p.31, 2007.
BLOCKLYGAMES. Accessed: 2016-02-19, https://blocklyResource-games.
appspot.com/.
BLOCKLYRESOURCE. Accessed: 2016-02-19, https://developers.google.com/
blocklyResource/.
DECISION Support System for Agrotechnology Transfer (DSSAT). Accessed: 2016-02-27,
http://dssat.net/.
DONMEZ, M. A.; SOONS, J. A. Impacts of Automation on Precision. [S.l.: s.n.], 2008.
p.117–126.
GNU Make. Accessed: 2016-02-19, https://www.gnu.org/software/make/.
KOEGEL, J.; HEINES, J. M. Improving Visual Programming Languages for Multimedia
Authoring. World Conference on Educational Multimedia and Hypermedia, [S.l.], p.8,
1993.
MARRON, A.; WEISS, G.; WIENER, G. A Decentralized Approach for Programming Interac-
tive Applications with JavaScript and Blockly. AGERE!, [S.l.], p.13, 2012.
43
MYERS, G. J.; SANDLER, C.; BADGETT, T. The art of software testing. [S.l.]: John Wiley
& Sons, 2011.
NOF, S. Y. Springer Handbook of Automation. [S.l.]: Springer, 2009.
OPENCV. Accessed: 2016-06-03, http://opencv.org/.
PARASURAMAN, R.; SHERIDAN, T. B.; WICKENS, C. D. A Model for Types and Levels of
Human Interaction with Automation. IEEE Systems, Man, and Cybernetics Society, [S.l.],
v.1, n.1, p.286–297, 2000.
ROBOT Framework. Accessed: 2016-01-12, http://robotframework.org/.
SHU, N. C. Visual Programming. [S.l.]: Van Nostrand Reinhold, 1988.
SIKULI. Accessed: 2016-04-19, http://www.sikuli.org/.
SILVEIRA JúNIOR, G. da et al. Análise da ferramenta de programação visual blockly como
recurso educacional no ensino de programação. [S.l.: s.n.], 2015.
SIMANIHOT. Accessed:2016-02-27, http://w3.ufsm.br/simanihot/.
SOYSIM. Accessed: 2016-02-27, http://soysim.unl.edu/.
STRECK, N. A. et al. Simanihot: um modelo de simulação do crescimento, desenvolvimento
e produtividade de mandioca. 13ž Reunião Técnica Estadual da mandioca e Reunião
Técnica Estadual da batata-doce,Cerro Largo -RS: Emater-RS, [S.l.], v.1, n.1, p.55, 2015.
TESTCOMPLETE. Accessed: 2016-04-19, https://smartbear.com/product/
testcomplete/overview/.
UIPATH. Accessed: 2016-04-19, http://www.uipath.com/.
UNIX Shell. Accessed: 2016-02-19, http://www.cs.columbia.edu/~sauce/
tutorial/shell.html.
VENKATRAMAN, N. IT-Enabled Business Transformation: from automation to business
scope redefinition. ABI/INFORM Global, [S.l.], p.73, 1994.